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Absitact 

The RstBVAKCE Language is a key component of the AovicbNbt syrtem, enabUna 
authors of advlaories to specify with predslaa the computers for which a certaiil advliow 
ID relfiW. This document describes the form*! stractiue of the lanauage and plac« 
In context the many cossideratloiie which have led to the current efetoctiwe 



Confidenfaallty Notice. The information contained In this documentation is Coofi- 
dentnU and Proprietary. It iB not for distribution oiitsid« of Universe Communica- 
tiona, Inc., which holds the Copyright on the document and aU trademarking and patent 
rights covering names, concepts,- and procedures contained ineide. 
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1 PRELIMmARIES 

3 

1 Preliminaries 

docvunentdescribes the Rblbvancb language of AdvioeNet . It aims only to provide 

maintenance. Describes the AdviceNbt system for oommunicating active advirte 
to comimters ^rld^de. Describes the impact of thi. system L comj^^ 
the «^stmg ends. Describes the devdopment effort needed for a computer «,fl 
Z^^^"^ n^'^- or a corporate intranet admlnsitratcr. to bLfit C 

' ^^''^^^ Sn-B. DEVELOPER'S Manuac, D^cribes the components of an 
advice arte and bow a« advice provider can construct those oomponente. S^lt^ 

X" """"^ ^"""^^'^ ^ ^PP*"* 

' R^T wf^f INSPECTOR API. Describes how ^ advice provider can e:ctend the 
^VANOE langjiago to include capabiKties directly addressing specific needs of the 
^ provider. Givee detailed infomiation on the Applications Pr.,gn«aming Inter- 
face and on the prograxnmmg enviromnent which is required to develop Insp^tors. 

' ^Sfit^^^SL^'i" ^'^SP^^^^^ I>escribcs a layer of M«d«tosh- 

Sth! ^""V^ ' Elements, and Casts which aupplemeuts the base Relevance language 
with a comprehensive range of services for inquiring about the state of a MacOS com- 

' '^■^rT^^ ^^'^^^ XN3PBCTOR LIBRARY. Describes a lajyer of Windows '95- 
specific Types. Properties, Elements, and Casts which supplements the base Relevance languege 

with a comprehensive range of services for inquiring about the state of a Wlntel '95 
computer. 

These documents are currently atiU under development. 

2 Role of the Relevance Language in AdviceNet 

s^S'n*?!>,t*tS?/'*i; * Jt°^f °f lUiLEVANCE language, we begin with a 

aketehof the. role played by the language in AoviOBNErr. 

The Ai^CeNbt system is based on the Idea of a decentralized community of advice 
SS^l^^ T'^iJ^,?"*"^"*^ worldwide throughout the Internet. These advice 

A^n S^rf^ ^K..^^ access spsdaa documents caUed advisor/as. Advisories are 
ASCn tert files resembhng very much in format existing e-mail messages; in fact they are 
^o« «ct^ions of the e-mail/MlMB message formats offered thxou^ Internet StaS^d 
RPC 822, It IS expected that at some future date, the ADVlCBNET^nsions 
proven fio widely useful that they wiU become Internet standards themselves 

Advisories have a Wat resembling the format of e-mail messages, with many of the 
same components In the message/digest header. The key erosion offered by ad^ri^ 
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3 DESIGN GOALS OF ADVICBNET 



iB the inatitutioa of a new cUuse la the message: the relevance clause. The relevaiioe 
clause is diatmguished by the keyword X-Relevaat-When: ; what followe the keyword is aa 
expression from the Relevance language. It is this language that ia being described in 
this technical report. 

The purpose of this language is to enable the AdviobNet Advice Reader, running on 
a user's computer to mtom^iically read an advieoiy and determine, without intervention 
irona the user, whether the advisory is re/eranfc to the user. Under the mediation of various 
user mterface parameters set hi the Advice Reader, the user will lypicaUy be notified of 
.relevBOt advisories, and will be given the opportunity to follow.1ihrough aa the advisories 
suggest. The eotual fbUow-throu^ action will depend on the advisory, but typically this 
will be an option to obtain and execute an application which rendera. In a fully-automatic 
way, a repair to an imdesirable situattoa. 

This scheme means that it ia possible for an advice author to publish advisories at its. 
web site that solve many of the most common technical support problems feoed by clients 
of the author's organisation, and be sssuzed that the advisories come to the attention only 
of users of precisely the computers that are la need of the specific advice being offered. The 
v^ue in this procedure is that it saves humans the time and trouble of precisely matching 
solutions to. computers in need of those solutions. 

With this background, the RblevaMCb language can be seen as fitting Into a context 

of 

(i) Widespread distribution via Intemetj 
(li) Unattended automatic parsing aad evaluation; 
(ill) User notification of relevant advisories only. 

It is particularly importaat to keep In mind that advice is evaluated for relevance con- 
tiTiually, Tha* is to say, andvlsory, once loaded into a computer's advice reader, can reside 
in the advice reader for an unlimited amount pf time, and caa continue to be checleed day 
after day, imposing a de facto constant vigil watchmg the eystem state for conditions as they 
develop. Hence it is particularly Important that the system be designed with unattended 
operation la mhid, and that unatteded operation be reliable and even conlidence-inapiriag. 

3 Design Goals of AdviceNet 

The Relevance language has been very specifically designed with this appUcation back- 
ground and purpose in mind. The design as it stands todeor ^ms at combining the following 
characteristics. 

• Engliah-AccessiWe. A relevance clause is, in principle, something an individual user 
could read and comprehend, though few users wiU dioose to do bo in most cases. The 
syntax of the Relevance language resembles the syntax of plain english, with key 
roles m the language played by clauses formed from articles like of, as, whose, exists, 
and 80 on. 

• Descriptive. The purpose of a relevance clause is to examine the state of an individual 
computer, and see whether it meets various conditions which could combine to imply 
the relevance of a certain advisory. In short the purpose of the language ia to describe 
rather ihxi to vaanipulate. 
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4 SECURITY ISSUES m ADVICENET 5 

• iVbuprocedurai Uiililtt many lajiguages used in connection Vrtth the operation and/or 
mamtenanoe of computers, the Relevance language is not procedural: it does not 
speafy how to manipulate the contents o£ various fragments of memory. This is the 
flip fltda of being descriptive: there ia no useful purpose tha-t would be served by 
enabling tradiUonal procedural services: loops, assignments, and conditionals. Such 
services are not made available. 

• Open-ended. The purpoae of the language ta to precisely describe the state of a 
computer. This state can change as the user purchaaea new software and/or hardware 
or indeed as new software/hardware objects are invented. Consequently it is not 
poaaible to linilt in advance what are all the components of state that the laoguage 
will give access to; and the language is designed to give authors the ablUty to extend 
the language to express concepts about fiystem state that haven't yet been conceived 
of. 

• Object-Oriented. The language ia extensible using the discipline of object oriented 
programming (OOP). The OOP buazword means, hi our case, that we offer a Stronglv- 
T^fped, Polymorphic language. We foUow the strong-ljyphig philosophy in the extreme. 
We carefuUy define the coUection of aU objects one would like to query, and carefully 
apedfjr the methods for maidng queries, and forbid combinations that cannot be 
formed using our controlled collection of methods. We aim to avoid the usual proce- 
dural approach offering powerful, flexible, general purpose tools, which can .be used in 
many unanticipated ways. In the usual caaea where that approach is used, it is good, 
but in the setting we are studying, it would be dangejvus, OOP methodology allow^ 
us to design a controUed environment enabling powerful queries of the system state 
while remaming relatively secure firom misuse and abuse. 

• Securfty and Privacy Aware. Because the language is designed to be used in con- 
ditions of unattended operation over the Internet, it is very important that the 
language be safe in various w^. This concern haa Overwhehned all others in the 
design of the product; it is fair to say that each of the distinctive features of the 
ReubvaNCE language has been chosen based on these important concerns. It is be- 
lieved that the language itself beat addresses the security and privacy concerns that 
mternet . operation will demand. 

4 Security Issues in AdviceNet 

The Internet is not a secure medium; along with the many services which it provides oome 
the risks of exposing one's machines to potentiaUy errooeous or even malicious agents. 
In deaigoing the AdviceNbt system, with its aspects off decentraJized authorship and 
unattended operation, it is crucially important for the acceptance and usefuhiess of the ■ 
system to address Internet security concerns. 

We begin with the obvious aanment that there is no such thing as an 'lionclad" guar- 
antee of security. The Relevance language has been designed with several security issues 
m mmd; the design addresses these isauefl, though there remains the possibility of other 
concerns we have not thought of. Your mileage may vary. 

Our mahi concern is that the evaluation of claiises In the language not have damaging 
or embaxassing side-effects. In evaluating clauses of the language, ideafly we would have 
these four properties: 
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4 SECURITY ISSUES IN ADVICENET g 

1. No sisnWc&nt aaim on ^yatcm resources. Evaluatioa of a rdevance clause should not 
consume inordinate amonnts of CPU time, CPU memory, or hard drive epace. 

2. No permanent change in system sUibe. The ©vahiation of clauses cannot effect the 
aystem, for example through creating or destroying files. 

3. No violation of user pilvau:y. The evaluation of clauses cannot result in an advisory 
communicating private data about the user to the outside world. 

4. Robustneee agaSzwt misuse of the Zangua^ Desiderata 1-3 are not only supposed to 
hold in evaluation of well-formed clauses authored by those with ''friendly intent". 
The evaluation of arbitrary clauses, even those vrhich aie malformed or which are 
authored by agents with "hostile intent^ should never be able to lead to damaging 
side^ects. 3Fbr example, the evaluation should be safe despite subtle mis-uses of the 
language - improperly formed clauses, misappHed operators^ or mismatching data 
types* 

Theee diS&rent concerns have dictated various aepects of the language design. Fbr 
example, the Relevance language is nonprocedural; this responds to security concerns, as 
it places limits on the leBOixroes which evaluation can consume. At an elementary level* the 
Relevance language does not allow for recursion, for infinite loops, for arbitrarily^sized 
arrays to be allocated; these Umits allow exj^idt bounds to be known (in principle) about 
the resources which a relevance clause can consume, A famous problem hi logic concerns 
the alality to predict whether a machine evaluating an expression in a procedural language 
wiU ever reaA completion. This is the 2Vzrm^ JTaitii^g Problem. It is not m general possible 
to decide whether a program in a procedural language will ever terminate. The situation 
in our setting stands in stark contraat; 

Ail RBLevaj^ge expressions are dccfdaWe: they must halt 

The object-oriented nature of the language also responds to security concerns. As the 
language is strongly-typed, it is not possible to apply operators to data which they were 
not designed to support. This allows to avoid crashes and dangerous misreferencea, and to 
safely terminate the evaluation of expressions that are poorly formed. 

A second facet of the object-oriented design which may be viewed as a security fear 
ture is the fact that manipulations of data are obtmned not in the surface level of the 
Relbvakob language itself but rather m the deeper level of the member functions of data 
types. These can be expected to be prograxomed more carefuUy than would be customary 
in the programming of a script, and to pay closer attention to clever use of computational 
resources. Moreover, they provide services which are available only after they are explicitly 
haatalled by the user, who therefore has a chance to apply scrutiny to the reliabiUty and 
authenticity of the provider. 

In general, our goal is that the user of AdvicbNet should foce no more exposure to 
flccurity rlsk$ than a user normally suffers through routine Internet activity. We behave that 
in many AdvxceNbt Creates fewer risks than existing widely used technology such 
as Web Browsers, in the forms in which such technology is often used (e.g. with "Cookie 
Dropping** enabled). 
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5 PRIVACY ISSUES m AJaVlCENET 7 

5 Privacy Issues in AdviceNet 

j 

Modem PC*s contain an enormous amount of mformation about their users, some of this 
: highly sensitive. It is very important for the acceptance and usefulness of AdvicbNbt that 

J we aim at the goal 

i LifoTmAtitm on the machfjse stays on the macfaineL 

I In accessing advice and fiubsequent evaluation of relevance clausea tto aim aJt two key 

principles 

•j 1. Subscriber Anonymity. No one should have a syatematic vmy to know who is sub- 

1 scribing to a given advice site; in the standard AdviceNbt eyatem, it is not consider 

acceptable behavior to require the names and addresses of subscribers. 

2. No I*eedback. No one should have a sjn^tematic way to know whi<^ advice is relevant 
on which ma^iunes- There Is nothing in the evaluation mechanism which can provide 
j information about the user's uaachlne to any other party. 

■ ! Point 2 is particularly worth examining. The lade of feedback remains true even if « 

I malicious party iias published hbrarles which cpmmunicate usfn^ the Internet Because the 

RblEVANCJE lan^age has a strict object oriented definition, cmd all object references lead 
to function calls with literal constants, it is not possible for a relevance dauae to evaluate 
i a function with an argument that is the result of an expression- Therefore even security 

'J ^ holes cannot lead to publication of private Information. 

We aim for no more exposure to privacy, risk than a user normally suffer^ through 
routine Internet actl^ty 

6 More On Security and Privacy 

The main ingredient of good security is the user^s common sense: he/she should deal only 
with trusted, responsible advice providers. As described in the document Tire AdvfcelVet 
System, there are various ingredients in the system wlxich, supported by trust mechanisms, 
deliver reasonable expectations of security. 
■] Aji importaxit ingredient is the division of labor between Relevance language and the 

.| rest of the system. The Relevance language does not offer the ability to fix problems, 

•| *^^y identify them* Fixing problems can only be done upon user approvsL This gives 

' :i a layer of insulation and a chance for reflection. The user is free to not approve that 

1 certain tasks be done; the user is free to study the situation before heeding an advisory, 

■j and in particular to inquire whether the advice itself as stlU being offered by the trusted site 

I that first provided it, and whether the advice really was provided fay that site, By theiJe 

mechanisms, it is possible to protect trusted sources of advice, avoiding contamination by 
:\ outside advice, pretending to be from a trusted source. 

! A further very important component is the recursive nature of the advice system itself. 

1 It is possible for an author to publish advice disowning earlier advice from the same author, 

recommending that it be removed frora 'one*e system; it is also possible to publish advice 
j recommending not to heed advice from conflicting or dubious sources. 

In short, the AdviceNet system contains a variety of tools addressing security issues; 
! it is not the responsibility of the Relevance language alone. 
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7 PROPEillTBS OF THE RELEVANCE LA2VQ17AGB 8 

It muBt also bo admitted that there ore security and privacy risks in AoviCBNErr . 
However, theso essentially do not involve the REbBVANOB lajiguage. 

The greatest samriiy risks involve what happens when a user decides to foUow tlwouBh 
on a piece of advice. At that point, m principle, anything is posaibfc; when the user saya 
OK" he/she is eSectivdy opening the machine to the advice provider who is thea in a 
position to perform surgery of whatever magrdtuda. 

It ia Ukewise true that user approval poses the greatest privac;/ risks. The appltcatioa 
that rum in response to user approval haa, in prindpla, the ability to cormaumcatc to 
the Advice Provider, and there are no real restrictioiw on what can be communicated. 
An Advice Provider can know if a certain action (update Or modificatioii) something was 
approved by a certain user at a certain time. This can reveal useful information to the 
provider, since the provider is learning that a complicated condition on the aystem atate 
13 true. Depending on the complexity of the condition, the information revealed may be 
eiibetai«tial. 

Although the security and privacy risks that would be posed by Improper design of the 
RJBLBVANOB language are not serious compared to the risks posed by indiscriminate user 
approval of untrusted fonow-through, it is import?«t to pay careful attention to these risks. 
It can be anticipated that AimcBNET wIU parse and evaluate many tens of thousands 
of relevance clauses for every clause that is found to be relevant. Hence numy orders of 
magmtude more work will be done without user intervention than with user intervention. 
Eiaks posed by the evaluation process, even if suffered only rarely, might potentiaUy have 
a numerically far more Important role than other risks posed by the syatem. 

It is also important to point out that in special drcumatancea, one might not want the 
secunty and privacy features to be available. One cam anticipate that In a secure intranet 
setting, barred firom outside aoeees by a firewall, it would be useful for intranet managere 
to be able to know which machines on a corporate network respond 'Relevant' to certain 
quenea. In that event, it would be usefiil to disable some of tha restrictions we have placed 
on the language in tha design discussed here. Our design goal emphasizes security and 
privacy, but in certain VBraions of the final product other cmpbafies will be possible. 

One can also imagine that certain advice providers will want to know who is subscribing 
to advice because they are selling advice and need to make it available only to paying 
customerB. This arrangement violates the stated privacy goals underlying this document. 
However, while we emphasize privacy goals, we win also enable applications in which such 
goals are secondary. 

. 7 Properties of the RELEVANCE Language 

We now describe important detwls a3>out the language structure and function. Given the 
earlier discussion, certain of the information presented he*e will appear repetitive! it seems 
beat to be absolutely escplidt about many details at this stage, and this seems to require 
repetition. 

T.l Descriptive Language 

Tha Relevance language is us^ for queiying the state of a computer, a highly complex 
arrangement of software, hardware, and data. It is a description language Which describes 
state rather than a procedural language which describes actions. As the language is not used 
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7 PfiOPJSilTZBS OF THE RELEVANCE LANGUAGE 9 

for traditional procedural tnAa (o.g. sorting data, moving data) it is profoundly m^eat 
from a trax3itional procedural language. There aro 

• no named variables 

• no assigiiineiit statements 

. no function calls, or at least no explicit fimction callo with variable axgumenta 

• no loops or conditional execution 

Neverth«lesB, the langoage is designed to be powerful, in that it is intended to be hJgbfy 
fflepress/vw; a kvr words in this language provide access to answers about the ayetem state 
which would be impossible to obtain in traditional progranming languages short of writing 
hundreds of lines of code and invoking many specialized fonctions In eyetem libraries. 

Certain tables can be done either in a descriptive language or in a procedural language: 
the cod© > a RELEVANCE language wiU typicaJly look very different than the code for 
the same task in a procedural language, and the way of productively thinking about how 
to accomplish the ^ame taak wiU be very different between the two languages. It will be 
importan* for some programmers to remind themselves &om time to time the main reasons 
why a relevance clause ahou/d be vwy diiferent from a program in a procedural langusge. 
Three good reasons are ■ ^ ~° . 

• Because procedural langaugea pose security Ss privacy concerns; 

• Because descriptive languages can be more ficnnomicai (in terms of code length) for 
the purposes of writing relernanee clauses; 

• To make the distinction in puipoSe starkly obvious to programmers. 
7.2 Lagrered Language Definition 

It must be understood that the Relbvancb language is very open-ended, and that it is built 
np m layer upon layer of extensions. In this document we only give detaUed information 
about the base 'built-in' layer; with a few hints about other layers. 

It must also be understood that the layers interface via object^orieoited programming 
techmques. Hence the capabUities of each additional layer axe delivered in packages "plug^- 
in" new object-oriented deUverables. In the Relevance language these are datatypes, dsJ;a 
properties, data elements, data casts, and operators. 

Hence, to understand a completely installed system is to understand the layers which 
hav© been installed, and to understand the object-oriented services that each layer provides. 

We aividon that hi o typical mstallarion, these layers will go as follows: 

• Base Layer. Contains the basic mechanics of clause evaluation: the Lexer, and the 
Parser for the language syntax, along with a number of Basic Buill^in types, prop- 
erties, elements, casta, and operators. It is expected that the base layer wiU be the 
same on every platform carrying AdvicbNbt . 

• Syatem-SpedBc L^r. This oonsistB of Plug-ins which give basic system information 
about a certain family of oomputeKi. For example, one might be able to get the 
system date and time, the size of various files, the contents of the PRAM, or the 
names of attadied peripheral devices. It is expected that these wiU all be in common 
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7 PHOPERTIES OJ? TAB RELEVANCE LAWGUAGE 10 

for a given computer OS family - Win '95, MacOS - independent of majiufacturer. 
It IS expected that these will be similar &om one OS to another - the object oriented 

Btructures and queries being basicaUy the same - but perhaps with naming difference 
(e.g. "Folder" on one OS might be "Directory" on another). 

• Vendoe-Speemc Layera. f his coUection of potentially a large number of "ejctensione T74.G^ 
Layers" would typically be produced by third parties giving special access to the 

mtemala of their hardware and software products: one can think of potential authors ^ '^"^'^ 

ranging a span of products from hardware producers (of, say, Cable Modems) to / j 

software producers (of say Photoshop & Plug-Lia); to service providera (e.g. Amiica ^^^^ 
On-Llne). 

It is expected that 80% or more of the power of the Relevance language wiU be 
provided through services off^ ed outside the Base leiyHr. 

We do not at the present time hawe any thoroughly thou^t-thiough examples Of Class 
Libraiies outside the Bsiie layer. Obvloiiaiy this is an important next step, which we expect 
to describe in two documents: 

- The AdvicbNbt MacOS Inspbotor LiSRAKi-. Describes a layer of Macintosh- 
specific Types, Properties, Elements, aiid Casts wMdi supplemraits the base Relevance language 
with a comprahenaiva range of services for inquiring about the state of a MacOS com- 
puter. 

• The AdviobNbt W1N95 Inspector Librakv. Describes a layer of Windows '95- 

spedfic Types, Properties, Elements, and Casta which supplements the base RELEVANCE language 
with a comprehensive range of sarvicea for inquiring about the state of a matel '95 
computer. 

7.3 Expected Conditions of Use 

We anticipate that many advice providers wiU use the Rblevancb language under the • 
following conditions. 

• A programmer will author adviaories contaJaing relevance clauses. 

• Relev»ace dausea will typically use types, operators, elemants, properties &om exist- 
ing inspector libraiies to. obtain their' expKSSive power. 

• Very occasionally, the programmer wUl discover that a key property (say of a hardware 
product) is not maAe available through existing libraries, and wiU author such a ' 
.property plug-in. 

• The programmer's advice will depend on the existence of various plug-Ins for its well 
functioning - both widely available pre-existing class libraries and his own newly^ 
developed plugins. He will have the responsibility to verify that libraries are correctly 
installed. It is nsceasary to write metsr-advice to verify this. 

Thus the prograanmer has these respoasibilitlea: 

• To know the base language and system-specific inspector libraryj 

• To write the relevance clauses for his advice mring those inspectors; 



anoao in™ mm nn os9 m n'L\ m nmzm 



S THE OBJECT MODEL 



• (Occasionally) to extoml the collection of eacisting types and properties; 

• To write metara4vice verifying that the language Is properly conBgured to correctly 
evaluate his advice. 

8 The Object Model 

While a computer language mvolves both syntax and a collection of semantics for manip- 
ulating data structures, we have chosen in this document to begin with the xole ot4ata 
structures and semantics, and latw to discuss syntax. 

As discussed earlier, the RELbvancb language is objectoriented, whidi means in our 
case that 

• The language is stronglj^iypedi every object has a specific type, and operators and 
properties may only be applied to objects of appropriate types. ^ some non-object- 
orimted languages, it is poa^ble to misuse functions, api^yiag them to data for which 
they cannot work properly. This is not possible in the Relevance language). 

• The language is polymorphict the meaning ot an operator or property reference de- 
pends essetially on the type of the direct object. This is also called ovsrlodding of 
operators fc properties: the. interpretaticm of an operator or property depends heavily 
on the data to which it will be applied. 

The language differs firom some other OOP languages m that the concept of encapsulation 
is de-emphasized. There is no distinction between private, public, a*id protected data. Or, 
more predsely, all data are public. 

In the current revision of tMs document, Version a .10 , the important object-oriented 
notion of inheritance will not be discussed; although it is expected to ultimately be included 
in the system. See Section 8.4 below. 

8.1 Objects and Methods 

An object in the Rexbvancb Isnguage may be thought of as a reference to a physical object, 
such aao-fileov SCSI device. It is implicitly a data structure, to which can be appHed accee$ 
methods made available in the H^levanoe language. 

Every object has a type^ and each type has associated with it several accessor methods. 
The language has four base types, which are essential to the workings of the language 
interpreter, and many esdieneion types which are essential to the performance of useful 
work» 

The base types are 

• Integer. A signed 32-bit integer. 

• String. A variable length character string. 

• Boolean. A single bit. 

« World. An abstract type, representing the computer of which the language is running- 

The Relevance language aecessor methods can be thought of as giving answers to 
structured queries about objects. They are strongly-typed: aji accessor may only be applied 
to a type for which a definition of that accessor for that type has previously been registered. 

Accessors themselves have various classifications: 



f 
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8 THE OBJECT MODEL 

• Properties; methods which inspect an objoct and return a value. 

. -Kemente methods which inspect b« object and under the control of a single param- 
eter, return a value. Often these are components of the object's stmcture and hence 
axe called elements. BlemenUOy-ilndex takes an integer; Element^by-Name takes a 

. Op^tors: methods which inspect an object (unaxy operators) or a pair .of objects 
(Wnaiy operators) and return a value. These are invoked syntactically by the usufil 
arithmetic and relational operators as commonly encountered in high-^level Wuafles- 
but there is no requirement that actual semantics be familiar. The interpretation of 
a + b need not resemble the usual interpretation - if a and b are not of integer type. 

• Coate methods which inspect an object end return a new object with a diferent type 
or, In some cases, the eame type but a different format. 

The purpose of the type-method iq^stem ia to make available powerful query and ma- 
nipulation tools but only undet strong-typing reatricttons that inhiTxLt miaose. 

8.2 Under The Table 

"^.^^i*^^^*^ language object system is intriaaicfllly connected with the object system 
pToviaeq ay u++. 

Ba^'iype, Operator. Propwty, Element, and Cast defined in the langu^ 
to a class, an operator, or a public member function in C-f.+ 

In factj^extenalona to the base set of types 8l« provided by writing appropriate C++ 
oode; see the document The AdvicbNbt Inspector API for an eacpWtion how this ia 

We can view the library of extension typ™ as piwiding a rich library of C++ wutiues 
. tor querying the system state and for tnanipulating the answers that get returned. 

We can therefore view the RELEVANCE Language as a tool for providing access to such 
a Hbraty while imposing strong-typing reatrictiona which inhibit abuses. 

8.3 The Object Universe 

The bulk of the funct JoaaUty of the RbleVANCE language is provided by the extension types 
whi<± have alrt^ady been mentioned. These can be conveniently organised as a mathematical 
graph structure, In which nodes represent types and arrows represent acc^s<n- rnethods which 
return properties, elements, or casta of those types. 

The structure Is rooted at World, which has maiy properties. On the Macintocsh, a few 
of these are: 

Properties of World 

• System Folder. Returns an object of type JbWer associated with the gyHtem folder. 

• Boot Drive. Returns an object of type Volume associated with the boot volume. 

• Processor. Returns an object of type aPJ7 associated with the computer. 

• Printer. Returns an object of type Printer associated with the currently chosen 
pnnter. 
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• Monitor. H;eturne an object of typo Monitor. 

• IPAddresfl, Returnfl an object of type IPAddresa, 

We can list a few elements as foUows: ^ 
Elements of World 

• SCSI Bub Integer, Hetunisanobject of type 6^(75/ Z>«u»cc ass 
SCSI Bua slot, 

• Serial Port Integer. Returns an object of type SeHal device associated with the epec. 
ia»sd SCSI elot. . 

It should be deax that, in general, there is a dose connection between methods and the 
lypee that they return. Often these even have" the same natoe. Remember, though, that 
the method that has name 'Ptocessor* obtains a property of World, not of Processor. 

The methods epplicafele to Worid generate a series of types with their own methods* 
those methods in tuni generate other types. For example, au object of type Volumt hai 
properties IMWand Ftlt^AUocation-Blocksize and Capacity and FrccSpace, while an object 
of type CPU has pwperties Name, Speed, FPU, MMX, and so forth- 
Some of these objects are of atomic type; Speed when applied to an object of type CPU 
yields an object of integer, type; while Volume Name, when appUed to an object of type 
Volume yields an object of type string. However, some of these objects are of new type: 
witness Driver, which is an object with properties such as Vendor and VerHoru 

In a future version of this document we expect to work out in detail ail the types aiid 
methods associated with two areas of special interest: 

1. Internet Settings example 
2- Volume examples 

8*4 The Evolving Universe 

The object model we are describing here is still under development. Two major enhance^ 
ments to the system described here are currently under development. 

• Inheritance. A basic platform-independent type (but with platform-dependent im- 
plementation) is File, This is an object with the following properties on MacOS: 

— Name« Object of iype Filename. 

— Creation Time. Object of type Time 

— Modification Time. Object of type Time 

— Length. Object of type Integer, 

— CheckBum- Object of type Integer. 

— Parent Fblder. Object of type Folder, 

— Version. Object of type Versiovu 

— lype. Object of type MacFileType. • 

— Creator. Object of type MacFUeCreator. 
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8 THE OBJECT MODEL 24 

Under MacOS, there are obo files with epedal properties, and hence having their own 
specialized types: Application, Control Panel, Extension, Fox example^.aa appUcation • 
has all the properties of a file as tv^U oa a PaHiHon Size, Recommended Partition Size, 
Minimum Partition Size, and Bundle Bits. A control panel has all the properties of 
file, OS well as the property Enabled (a Boolean). 

In traditional OOP systems, one would handle such iesuca hy creating a base type 
FUe and derived types Application, Control Panel, etc. The derived types accept all 
the same accessor methods ea the base type FUe, md objecte of type Application, say, 
accept also the axxsegsor methoda for that type,.auch as PaHHion Size, We expect 
that the RELKVANCE language will ultimately do thia, though the details remain to 
be worked out. 

♦ Plural Properties, It is important for certain purposes to know that there only be one 
of a certain object in axiatenoe, while for other purposes, it does not matter if there 
be one or mora than one instajace matching a reference. 

As a convenieait way to mate it possible to verify either circumatarice, the Relevanoe language 
will offer plural properties. 5br example, the property applicaUon is singular and the 
property applications is plural. The distinction is this 

- application "MTetscape" asserts the existence of carac% one application named 
Netscape in the scope. Clause evalaution will generally fail if there is no such 
application or if there are more than such application (see Section 9,2) for infor- 
mation about the mechaniem behind thi8t 

- applicatioaa "Ketecape" asserts the existence of one or more than one appli- 
cation named Netscape in the scope. Clause evaluation will generally fail only if 
there is no such application (see Section 9.2). 

The existence of m ng n l a r and plural properties means that phraaes have (by inference) 
singular or plural diaracteristics* Accomodating thia will require certain modifications 
to the grammar and semajitics of the language, which remain to be worked out. 

8.5 Describing the Universe 

In order to keep track of all the types and methods available in AdvioeNETT , we will make 
available a Type Inspector, a spedalized dictionary indicating all the available types and 
their associated methods and the results of thse methoda. 

This dictionary will be rendered in two different ways. In an on-line version, it wiU offer 
a hyperteirt-fbrmat dictionary describing each relevant term and the associated definition 
and relationships. This will be reminiscentj for some readers, of the Clasa Dictionary in 
AppleScript [1]. 

In a pritited version, it will take a standojd format reminiscent from typical system 
manualfl for UNIX and related operating syatems. Roughly speaking, we expect a single^ 
page description of each type, taking the form 



mm mvd Maio \m m oso m n-iA m nmim 



os-k:(ss^uui) Noiivuna , m m mm « 9oe6zz8:siNa i i/i-Jiixd3-oidsn:iiAS . Ni misti m mmim ami « m\ 30Vd 

8 THE OBJECT MODEL 



Typename - i-iine synopsis 

SM:^ for ssSii*^: Sir ''"^ ^"^"^ "'^^ ^"^p-**-* 

SXSi^ujj'' ~ "^'^ '''^ ''^ 

Properties.. 

Wwe-Type. Description of what the value is supposed to be, and the type that it 



Elements, 

keywordl name Value-Type* Description. 

k^word2 integer Value-Type. Description, y 
« * • 

Unary Operators. 

unopl Value-Type, description, 

CaiBts. 

as 1Vp^>^^^^1 degcription 
« • • 

How-reach^, Deacription of Typ^s from which this type reachable as the value of a 
property or elemenL . 

propertyl of IVpel 



Related Oypes. DeacripUon of Ti/pes which have intimate connections with the curv^nt 
one, ettaer 

Typel Reason. 



Subtleties. Hairy points to keep in mind. 
1. Notel. 
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9 The Evaluation Model 

We now turn to rales for successful interpretation of clauses in the RELEVANCE language. 
9-1 Abort, Retry, F^ll 

Tlie basic purpose of the Relevance language ia to ewcessfully lex, parse, and evaluate a 
single expression, resulting in a value of type BoaleAn. The resulting value is passed to the 
AdvicbNet advice reader for further proces&hig. 

Of course, there will al%vays be cases where a Relevance clause is malformed or oth- 
erwise unacceptaWe. In order to deal with that situation in an organized fashion the 
lexer/pajeer/interpreter follows this rule. ' 

A Relevance Cle-use will lead to an advisory behig declared relevant only 
ifj the clause is intelligible, successfully evaluates to a result of type boolean, and 
is irue. 

Let's explain this rule in more detail: 

• E3q>reasions can be UnintelligiblG or InteiUgible. UnintelU^l^ expresBions occur for 
one of three reasona. 

- Lexical unuUell^ibUity. For example, the expression contains bizarre unquoted 
characters, such as S, 

- Syntactic unintelligibitity. Fbr example, the expression contains contains disal- 
lowed usage, such +-^ame. 

- Rufir^time ujiinielHgibiUty, Fbr example, the expression refers to an unknown 
property (e,g, exis1:s solaxplexue of file). 

• Intelligible acpressionfl can Succeed or J?)ail to evaluate, 

- Arithmetic FoUute. 65536*66636 overflows type integer. 1^50 
R^erence Fhiluve. picture resource 101 doesn't exist. 

- System FaUufie. There is an error reading the hard drive. 

• Successful evaiua;tLona can be Boolean or not* Escamples of types which are not 
Boolean; integer, TPAddress^ etc. 



9.2 Exception Handling 

The RJELEVANOB language interpreter creates two special objects to indicate ev^uation , 
fiulures. 

• NSO, which stands for *No Such Object'. 

• TMO, which stands for "Ibo Many Objects*, 

For example the expression length of file "f oo" evaluates to NSO if file "f oo" 
doesn't exist. 

NSO generally but not always causes expressiona to FAIL to evaluate- There are at the 
moment two exceptions: 

1* exiet3(KS0) evaluates successfully. 

2. exists folder whose ( length of file "f oo" of it is 8 ) evaluates success, 
fully if SOME folder contains a file "feo", even though many folders do not. 

The expression application "Netscape" evaluates to TMO if there are two or more 
applications which are instances of Netscape. 

TMO generally but not alwayg causes expressions to PAIL to evaluate- There axe at 
the moment two exceptions^ analogous to the exceptions for NSO discussed above- 
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10 Relevance Language Syntax 

We finally attempt a desaiption of the syniGx of the Relevance languagel 

10.1 Simple Examples 

1, Existence of a certain application. 

X-Rel^aat-Wheu; exigtB application "Photoshop" 

2, Comparison of veansdon numbers. 

X-R©l«vant-Wh«n: dxists Control Panel "MacTCP" and 

version of Control Panel "MacTCP" is version "2,02" 

3, Compare modificatiott dates. 

X-Ralavant"Wten: exists Photoshop Plugin "Picture Enhancer'* and 

modification time of Photoshop Plugin "Picture Enhancer" is 
greater than timo "iO January 1997** 

■ 4i Examine Control Panel Settings. 

X-Relevant-When: exists Control Panel "Conf igPPP»* and 

Transport Mechanism of Control Panel •'MacXCP" is equal to ^'SLIP" 

We now turn to a more systematic description of the language; consider in tumr 
I^eoacal analysis, Syntax, and Semantics, 

10-2 Lexemes 

The lexical analysis of the string breate up the input staring into tokens consisting of basic 
elementary mputs. ^ -^*v 

In the fbUowing, we wiU denote literal key^rds by enclosing them in curly braces 
tlilce this}, and we will denote general Lexeme Classes by [cla$s name]* 
Lesdcai tokens come in one of the following basic categories. 

{String. ] A string of printable asdi characters enclosed in quotatk>n marks 
[Integer ] A potentially signed string of dedmel digits. 

|Mrrais ] The character 
[SumOp ] The characters ' . 

[PrdOp ] The characters */. 

(RelOp ] The character sequences ->>=<= r .-. 

[Phrase ] A sequence of one or more unquoted words. 

These catagoriea are mostly unwcceptional, and will be famUiar to programmeis from 
work with other computer languages. 
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lb«2.1 Fhroecs 

The moet non-fltaiulArd aspect of the langua^ is in the definition of token type [Plirafiel 
PormHlly, a Phiase ia a string of words; a word is a string of characters beginning with a 
letter- Any Phrflse can be further decomposed into several occurrences of (Reserved PhraseL 
with, intervening word sequences (by definition) called [Ordinary Phrase], 

Here ia a partial list of 

Reserved Phrases. 

• es 

• and 

m containing 
« ends with 
» exists 

• is 

• it 

• number of 



♦ or 



• remainder 

• arfcaxts.with 

• whose 

These phrases are oU built into the base layer of the language, and have purposes 
associated with the base functions of the language; hence thi^ are reserved from other ufie. 
Here is a partial list of 
Ordinary Phrases* 

• Control Panel 

• Photoshop Plugln 

• Modification Time 

• MacFileTVpe 

• MacPiieOieatbr 

• SCSI Bus 

« Shared Disk 

• CD ROM 



These are all phrases that describe system-dependent concepts, and so th^ are associ- 
ated vnth the System-specific or Vendor-specific layers of the. language. The collection of 
ordinary phrases is not fixed in advance, and can be exepected to grow with time as more 
inspectors are added to the language. 

We note that one has Run-Time UnintGlUgihility when the lexer extracts an ordinary 
phrase from a string of words and cannot fmd that phrase in the current collection of 
installed libraries. 
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10.2,2 Special Notes 

1- Strings are aimply quoted seqttences of ASCII charactera. 

" V^}^ 8-priori length Kmit on stringe. It is a Syhtem EvaluaUon Failure 
tfttte lexer encounters strings so long that they cannot be stored in a-TOilable 

- RFC 822 imposes lezigth restrictions on atrings, 

— There will be a mechanlgm for continuing atrigs across lines. 

2. pcape secgjences will be specified, but have not yet been defined. Most likely usase 
Is to apecjfic ASCn codes explicitly by \DiZ>2D^ where the are decimal dirite 
eJthough hexadedmal and other coding schemes might be offered. However, issued 
of axxexits and other items that appear in connection with foreign character sets will 
have to be carefully studied. 

10.3 Formal Grammar 

In the table below, we denote concepts defined in the left-hand-side of Grammar Produc- 
tions by (name) 



<Goal> 
<Expr> 
<AndClausa> 
<Relal;ion> 
<SuiDClaufie> 

<PrQduct> 
<Unary> 

<CaBt> 
<Reference> 



<Expr> 

■ <E5cpr> {or> <AndClaufle> i <AndClaxxse> 

- <AndGlaufle> <ajxd> <Relatiou> | <Relation> 

= <SumClaiise> [RaXOp] <3ujnClanfle> | <SumClausa> 

■ .<SuniClause> [SumOp] <Product> 
<SumClauae> [Minus] <Pxoduct> 
<Product> 



[PrdOp] <:tJuary> 



<Product> 
<Unary> 

[Minus] <Unary> 
[UnyOp] <Unary> 
<Cast> 

<Cas1:> {aB> [Phrase] 
<Hef6rence> 

[Phxdse] {of} <Reference> 

[Phrase] [string] {of > <Reference> 

[Phrase] [integer] -tof> <RQf Grence> 

[Phraae] <R©strict> {of> <Re£erence> 

[Phrase] [string] 

[Phrase] [integer] 

[Phrase] <ReBtrict> 

[Phrase] 

■Cexiste} <Reference> 
inximber of} <Ilef Qrence> 
Lfltring] 

[integer] 



<it> 



<Redtrict> 



<£xpi:> ) 
{whose} C <B3cpr> ) 
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10 KELEVA14CE LANGUAGE SYNTAX 20 
10.4 Special Language Constraints 

There are two very Important special ccmfltraints imposed by the syntax of the language 
which we now dlscusa. Each one can be daaoribed in termfl of what the Relevance language 
does not allow w:hich prograuuners may be familiar with due to experience with procedural 
languages. 

10.4.1 Lack of variables in function calls 

fbr the lack of a better terminology, we have chosen to use (archaic) procedural lan^age 
to describe this special feature of the language. The U3a^ doesn't quite fit because the 
Relevance language really has no fimction calls. 

Still, we may think of **Element-by-Name'' aa Implicitly invoking a certain function with 
two arguments the first being an object, the second a parameter that selects the precise 
object. For example; ^ . 

file "Read Me" of/tfolder "P&otocftiop" 

might be coded in a procedural language as 

for <l«Oi KNVolumea; i-h+X 
Volnama ■ Volume [i]; 

FolderRof - findf older CVolname* **Photoehop"); 
l£<FolderIU.f !- 0){ 

FileRaf « getf lie (FolderRef , "Read Me" ) ; 

break; 

> 

Here folder "Photoahop" asks for an element-by-name of the World, which is eimilar to 
calling^ for each mounted volume, the procedural language function f indiolder (volname ,name} 
with appropriate parameters to have it aeardi a certain volume for a certain folder.* 

The key point Is that the syntax of the Relevance l^iiguage forces you to ask for 
spGciSc elements-by-name using atrxotg constants for the selectors. It is impossible to 
perform the anelog of csJling such a function with a computed name. 

Thus, one caji not aoy 

file (filename of file 3 of volume "Shared Disk**) of 
folder "Photoshop" of volume "Private Disk" 

This is a potentiaily useful script: one looks on one of volume for a file and looks for a file 
by the same name on another volimie. It is fortddden syntactically to do such thin^ in the 
Relevance languages 

The rationale for this taboo is the existence of security problems which would inevitably 
appear if it were tolerated. We expect that for many advice authors there will be a period 
of psychological adjustment as they adapt to this restriction. 

10.4.2 Lack of Nested Loops 

Since there are no variables or assignments in the RelbvanCb languagej one may wonder 
at first how one could obtain the equivalent effect of iterating across a list of folders or files 
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XI TO PBOBE FURTHER 21 

to chedc a condition* In the Recevange language /oopa o «nyfe level deep catx be handled 
by the use of the vhosa primitive, and the aasociated it reference* 

For example, suppose we wanted to find out if the user's Eudora folder has any maQ 
digest files whidi were laat modified before the ship date of the current release of Eudora. 

exists file of folder "Eudora^ 

vhos« ( modification time of it.ia less than time **12 January 1097" ) 

Here the whoso clause is causing the implicit iteration over ell files in the Eudora folder. It 
is useful to think of whose as o-eating a function with the single formal parameter it and 
then calling the function once for eech file in the faidlcated folder. 

On the other hand, suppose we wanted to find out if the user's Eudora folder has any 
mail digest files which are not accompanied by table of contents files. We might think of 
writing 

exists file of folder "Eudora" whose ( not eacists Cfile (prefix of it k ".cnt"})) 

This pseudo-fragment will not work because it specifies the forbidden usage "file (computed- 
result)" (see previous subeection) 
We inight also think of wtiting 

exists file of folder '*Eudor£i" 

whose C suffix of it-1 la .mbx" and 
not exists file of Folder "Eudora" 

whose (prefix of it ia (suffix of it -1 suffix of Ir-a is ",cnt") ) 

This psuedo-firagment is an attempt to make nested loops; we would like to have it-1 be 
the 'local variable' in the 'scope' of the /outer whose' and it-2 be the 'locaj variable' of 
the 'scope' associated with the 'inner whose' . Note however that these are vain impulses: 
they are not allowed syntactically. 

11 To Probe Further 

• Relation to AppleScript. 

♦ Readings on OOP. 

12 Appendix !• Properties of World 

13 Appendix 2. The Base Library of Types and Accessors 
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